[% setvar title More modules %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>More modules</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Michael G Schwern &lt;<a href='mailto:schwern@pobox.com'>schwern@pobox.com</a>&gt;
  Date: 19 Sep 2000
  Mailing List: <a href='mailto:perl6-stdlib@perl.org'>perl6-stdlib@perl.org</a>
  Number: 260
  Version: 1
  Status: Developing</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>Perl should come distributed with more modules.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>Currently, in order to get a really useful Perl installation you have
to immediately hit CPAN and download a battery of modules.  This is
kind of silly.  Its a tedious step that can be eliminated if we expand
what Perl comes with.</p>
<p>When a &quot;how do I do X&quot; type question pops up and is answered &quot;module Y
does X&quot;, a typical response is &quot;is module Y in the core?&quot;  There is
some trepidation about using CPAN modules because they must be
downloaded and installed (often a difficult problem for programs which
are to be distributed, especially to Windows and MacOS), and because
of perceived instability.</p>
<p>Core modules also establish a lowest common version.  If version 1.5
of module Y is distributed with Perl, yet version 1.6 is on CPAN, a
program author can code for 1.5's API and be fairly certain it will
work on most installations.</p>
<a name='Core bloat?'></a><h2>Core bloat?</h2>
<p>The most obvious objection is core bloat.  5.6.0 is already over 5
megs and only going to get fatter.  Throwing lots of modules into the
core will only make it even bigger, possibly getting up to 10 megs!
There are a few solutions for this.</p>
<p>The first is to provide several distributions of Perl.  A minimalistic
distribution might provide just perl and a handful of modules.
Another provides the docs.  Another a set of modules equivalent to the
current set and yet another provides our extended set.
CPAN/src/perl-X.X.X.tar.gz would be one big bundle encompassing all
these sets.  Other combinations might be made available.</p>
<p>Another is to provide several different install options.  &quot;make
install&quot; installs everything, as usual.  &quot;make small_install&quot; installs
just the current set of modules.  &quot;make tiny_install&quot; installs a bare
minimum, not even docs.</p>
<p>There's alot of crufy stuff in the source distribution that could be
dumped.  Eliminating lib/*.pl (except perl5db.pl) and eg/ will free up
over 200k which makes room for a couple more modules.</p>
<p>Finally, we've got about 18 months before Perl 6 is expected to ship.
In that time, DSL and cable modems will become more and more
ubiquitous (my <b>dad</b> has one!) and pulling down 10 megs will be less
of an issue for Joe Average.  Users still on low bandwidth can get one
of the slimmer distributions.</p>
<a name='Which modules?'></a><h2>Which modules?</h2>
<p>Some of the more obvious modules are:</p>
<ul>
<li><a name='DBI'></a><b>DBI</b></li>
<p>Perl talks to databases alot, and DBI is how you talk to databases
with Perl.  Distributing it would push Perl even further as a powerful
database access language.  DBD::CSV and DBD::RAM (along with their
supporting modules) would also go along, so even without a database
DBI is still useful for prototyping and provides a path for programs
to migrate to a real database when one is needed.</p>
<p>DBD::ODBC would also be nice, as most databases speak it.  The free
ODBC drivers should also be distributed.  They are firming up now and
by the time Perl 6 is out should be stable and well supported.</p>
<li><a name='LWP'></a><b>LWP</b></li>
<p>Rumor has it Perl has been used for some web stuff.  LWP is the most
obvious module for this sort of work.</p>
<p>LWP is quite fat, perhaps the maintainers could be petitioned to split
it up into a basic set and a set of extensions.  Perl would distribute
the basic set.</p>
<li><a name='libnet'></a><b>libnet</b></li>
<p>This Internet thing is getting pretty popular, and Perl should come
ready for it.  libnet provides all the basic network clients.  FTP,
NNTP, POP3, SMTP...</p>
<li><a name='Mail::Send'></a><b>Mail::Send</b></li>
<p>&quot;How do I send mail?&quot;  More often than not this question winds up with
something like <code>open MAIL &quot;|/usr/lib/sendmail -o&quot;</code>.  This is not only
non-portable, its also ripe for security holes.  Mail::Send, or
similar module, makes sending mail easy, safe and portable.</p>
</ul>
<p>The exact set is not so important as a consensus that its a Good Idea
to start distributing more modules.</p>
<a name='MIGRATION'></a><h1>MIGRATION</h1>
<p>None.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>The integration and upkeep of existing CPAN modules is already a
fairly well-understood procedure.  The only foreseeable problem is
configuring and testing those modules requiring network access, as
this is not always available.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>RFC 228 - Add memoize into the standard library</p>
</div>
